The invention relates to reserving quality of service in wireless telecommunication systems.
The Quality of Service (QoS) determines how data, such as packet data units (PDU), are processed in a telecommunication system during transmission. QoS levels determined for different connections control for example the order in which PDUs of different connections are transmitted, buffered (PDU queues) and rejected in various network elements. Therefore different QoS levels represent for example various end-to-end delays, bit rates and numbers of lost PDUs.
RSVP (Resource Reservation Protocol) is a well-known protocol for reserving quality of service required by any application in IP (Internet Protocol) networks. RSVP is used by a host to request specific quality of service from the network for particular application data flows. RSVP is also used by routers to deliver QoS requests to all nodes along the path(s) of the flows and to establish and maintain a suitable network resources for providing the requested service. RSVP carries the request through the IP network, visiting each node the network uses to carry the flow. At each node, RSVP attempts to make a resource reservation for the flow.
RSVP requests resources for simplex flows, i.e. it requests resources in only one direction. Therefore, RSVP treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack. However, RSVP does not transport application data.
To make a resource reservation at a node, two local decision modules, admission control and policy control, are used. Admission control determines whether the node has sufficient available resources to supply the requested QoS. Policy control determines whether the user has administrative permission to make the reservation. If either check fails, the RSVP protocol entity sends an error notification to the application process that originated the request. If both checks succeed, parameters in a packet classifier and a packet scheduler are adjusted to obtain the desired QoS. The packet classifier determines the QoS class for each packet and the scheduler orders packet transmission to achieve the promised QoS for each flow.
There are two fundamental RSVP message types: path messages PATH and reservation messages RESV. Each RSVP sender host transmits RSVP “Path” messages downstream along the unicast or multicast routes provided by the routing protocol(s), following the paths of the data. These path messages store “path state” in each node along the way. This path state includes at least the unicast IP address of the previous hop node, which is used to route the RESV messages hop-by-hop in the reverse direction.
Each receiver host sends RSVP reservation (RESV) messages upstream towards the senders. These RESV reservation messages must follow exactly the reverse of the path(s) the data packets will use, i.e. they are sent upstream to all the sender hosts included in the sender selection. They create and maintain a “reservation state” in each node along the path(s). RESV messages must finally be delivered to the sender hosts themselves, so that the hosts can set up appropriate traffic control parameters for the first hop.
RSVP requires refreshment messages to be transmitted periodically from end to end. Refreshment messages include path messages PATH and reservation messages RESV. An IETF (Internet Engineering Task Force) specification for RSVP, RFC2205 (Request for Comments: 2205), recommends a refreshment interval of 30 seconds, but each node can independently adjust the refreshment interval.
However, in wireless telecommunication systems, such as GPRS (General Packet Radio Service) networks providing a packet radio service, the bandwidth is a rather limited resource. Periodic refreshment required by the RSVP is uneconomical for the use of the radio resources.